Turnbull China Bikeride/Turnbull China Bikeride - Disc 2.iso/BARNET/ARMLINUX/MAIL/9805/000080_owner-linux-arm…r.rutgers.edu _Mon May 18 17:53:54 1998.msg

Internet Message Format | 1998-06-02 | 6KB

Return-Path: <[e-mail]>
Received: from virtual.bbc.co.uk (virtual.bbc.co.uk [132.185.132.199])
    by odie.barnet.ac.uk (8.8.6/8.8.6) with ESMTP id RAA10141
    for <[e-mail]>; Mon, 18 May 1998 17:53:52 +0100
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
    by virtual.bbc.co.uk (8.8.5/8.8.5) with ESMTP id RAA11656
    for <[e-mail]>; Mon, 18 May 1998 17:53:55 +0100 (BST)
Received: from vger.rutgers.edu ([128.6.190.2]:39698 "EHLO vger.rutgers.edu" ident: "root") by nic.funet.fi with ESMTP id <2769-14987>; Mon, 18 May 1998 19:53:40 +0300
Received: by vger.rutgers.edu id <970990-231>; Mon, 18 May 1998 12:52:58 -0400
Received: from gatekeeper.prl.philips.co.uk ([193.129.162.20]:3904 "EHLO gatekeeper.prl.philips.co.uk" ident: "SOCKWRITE-65") by vger.rutgers.edu with ESMTP id <974082-231>; Mon, 18 May 1998 12:52:45 -0400
Received: by gatekeeper.prl.philips.co.uk; id SAA19510; Mon, 18 May 1998 18:52:20 +0100 (BST)
Received: from prlhp1.prl.research.philips.com(130.141.10.82) by gatekeeper.prl.philips.co.uk via smap (V3.1.1)
    id xma019481; Mon, 18 May 98 18:51:54 +0100
Received: from prsun11 by prlhp1.prl.research.philips.com; Mon, 18 May 1998 17:55:49 +0100
Received: from marketto.demon.co.uk (herrena [130.141.143.176])
    by prl.research.philips.com (8.8.7/prsun11) with ESMTP id RAA23625
    for <[e-mail]>; Mon, 18 May 1998 17:52:37 +0100 (BST)
Message-Id: <[e-mail]>
Date:     Mon, 18 May 1998 17:52:10 +0100
From: Theo Markettos <[e-mail]>
X-Mailer: Mozilla 4.03 [en] (Win95; I)
Mime-Version: 1.0
To: [e-mail]
Subject: Re: PowerROMmed cards
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Orcpt: rfc822;[e-mail]
Sender: [e-mail]
Precedence: bulk
X-Loop: [e-mail]
Status: RO

>
>  This is the suggestion which was put to me:
>
>  Each driver which supports a card that can be fitted with a PowerROM should
>  check through the modules which are present on the card.  It should look
>  for modules of the form `*TX'.  This is the only difference between the
>  ROMs.  Apparently it would be prohibitively expensive to change the product
>  ID for each style of card.

I don't think so.  What would be expensive is to change the ID
_retrospectively_, on ROMs already out there or in stock.  I don't see why
any future batches of ROMs that are ordered can't have the ID changed -
getting a new ID is a simple as emailing the nice Mr Glover at Pineapple and
asking for one.

>  Here are the thoughts which occur to me:
>  2. How easy is it to read the chunk directory from the podule?  I did it
>     in a program called PodHacker once; I'll have to dig it out and see how
>     to do it.  If I used RISC OS SWIs and it can't be (easily|at all) done
>     under Linux then see suggestion 4.

The only possible problem is you need to know where the page latch was in the
address space, or call the loader, which could be tricky.  To clarify what
follows, the loader is a bit of ARM code stored in the first page of a podule
ROM that allows access to the rest of the podule ROM using a page latch.  The
page latch must be reset to allow the loader to be read out of ROM correctly
without the help of RISC OS.

Read the following slowly...

On bootup, the hardware is reset, so the page latch contains zero, and
therefore RISC OS can see the first page of ROM, which contains the loader.
If RISC OS has read data from ROM other than in the first page, the page
latch may be pointing to another part of ROM, and without know where the page
latch is, you can't reset it to find the loader.  In this case, you need to
call the loader from RISC OS to access the loader code in ROM - you can't
simply read the loader from RISC OS's copy of it, because there's no way of
getting a pointer to this copy.

Therefore, you'd have to use Podule_ReadBytes (IIRC) to read out the loader
(this uses the loader), make a copy of it, go into Linux, then call this
loader to read out the rest of the ROM. The loader might call a few SWIs (if
it is badly written - it doesn't have to), which could cause problems.

I don't know which mode Linux runs in, but there might possibly be problems
running the 26-bit loader code on ARMs in 32-bit mode.

If you know the page latch address, you can effectively duplicate the loader
in the Linux kernel.
This address should be easily hackable out of the ROM loader code.  It would
however be different for every type of podule, so you'd need a PowerROM for
each of these cards to find it out.

Thinking about this, it might still be possible to read the ROM without
calling the loader or knowing the page latch address.  IIRC a Ctrl-Break does
not assert the /RESET line on the podule bus, so if this is the case, the
page latch must always point to the first page of ROM, otherwise a Ctrl-Break
would fail to identify the podules correctly because it sees the wrong page
of ROM. This all depends on whether RISC OS scans the podules on Ctrl-Break,
or just on reset.

Once you can read the whole ROM image, examining the modules isn't too
difficult.  The ROM format is detailed in PRM vol 4, and it's merely a method
of decoding this - it's not too tricky a task.

Apologies if this was confusing - using a loader to load the loader is not
the easiest process to describe.  Mail me or to the list if you want more
info.

Cheers,
Theo

--
Theo Markettos          Home:   [e-mail]
Liphook                 Work:   [e-mail]
Hampshire
UK                      Web site, including Acorn backup software
                        http://www.marketto.demon.co.uk/
unsubscribe: body of `unsubscribe linux-arm' to [e-mail]